Database parallel editing method

ABSTRACT

Conventionally and generally, a plurality of computers access a database provided in a server. According to the inventions, generally-called full-fledged “parallel DB edit” using computers permanently holding duplicate DBs is presented. Computers exchange edit information on the duplicate DBs, and the duplicate DBs of the computers synchronize with one another. Each of all the relevant PCs takes out the local-edit records in the other PCs in a unique order (such as the order of arrival at the server) and updates the local original DB thereof. The edit information including the same contents is processed in the same order with the same logic, and then the local original DBs are updated. Therefore, the resultant local original DBs of the PCs also synchronize with one another. The synchronization is established not along with real time axis but along the common time axis which is the order of edit records. As a result, “substantially on-line operation” in which edit records are frequently taken in and updated and “substantially off-line operation” involving long update cycles can be mixed-ly carried out.

TECHNICAL FIELD

The present invention realizes parallel edit to database (hereinafter“DB” and “parallel DB edit” respectively).

BACKGROUND ART

There are typical operation types of DB.

“Single DB access” is an operation which operates DB only by onecomputer. Since only this computer can perform edit to DB, accesscompetition is easily avoided. But, it is not suitable for an operationin which plural computers to access a DB.

“DB access by server” is an operation, in which terminal computers(hereinafter “PCs”) access a server computer (hereinafter “server”) thatmanages DB. Each PC accesses DB through procedure of the server. Sinceonly one PC accesses DB directly, it is easy to prevent accesscompetitions. Pessimistic cursor (Non-patent literature 1) andtransaction lock (Non-patent literature 2) are used.

“Power-up newspaper sales”, which was developed under a control of theauthor, only permits parallel accesses of reading. “Editorial right”should be acquired before edit to a PC, in this system. And only one PCedits at a time. This is also a lock.

But, if it is impossible to communicate to the server, it is impossibleto access data. It is also impossible to get or release a lock. It willbe a big restriction, since communications are frequently impossible formobile devices. It is impossible to realize a request of continuationsof mission critical tasks, such as medical and financial activities andrelief at the time of a disaster. Even if communications are possible,inferior communications environment is insufficient for practical usage,because of extremely long response (that may be a result ofre-transmissions and so on).

By the art of cache which creates copies for temporal working, it istried to increase efficiency of procedure and communications. By ADO.NETof Microsoft, PC makes a copy of data (that is necessary for the presentwork) from server, cuts connections to the server and performs edit.After the edit, PC connects to the server again and sends results of theedit to the server. If target information of the edit were alreadychanged by other terminal computers, the later (this) results of editare judged to be invalid. It is possible to interpret it as “when a lockfailed as a result, the edit was judged invalid”. It is a kind ofediting lock. This is called “Optimistic concurrency control”(Non-patent literature 3 and Non-patent literature 4). However, theremight be inconvenience, at some occasions. That is as follows;

(1) Since a copy is created for every edit, the copying procedure andcommunications to the server are excessive work (p 19 of Non-patentliterature 1). For lessening them, it is necessary to restrict the rangeof the copy. However, it requires full knowledge of structure of thetarget (by the application program) information.(2) It is difficult to estimate that “information of cache is valid tillwhen”. If amount of cache is lessened in order to increase efficiency ofcopy, a possibility that the copy will be used for the next edit islessened. Large volume of cache is also a problem. Even if a portion ofcache was edited, “optimistic concurrency control” makes this cacheinvalid.(3) It is difficult to detect that “information operated (input,updated, deleted) by a PC is amended (deleted, re-updated, re-input) byother PCs”. This problem is common to “DB access by server” and “Cache”.Result of judgment about validity of edit (by this PC) becomes clear atthe time of the “sending up”. But, it is difficult to timely detect thechanging of information that was input in the past and judged onceeffective at the time.

Other investigations are shown below. Non-patent literature 5 is ainvention about file cache. When a collision (that is “competition” ofthe present invention) of among edits is detected, edit will be simplyrefused (10th line of lower right of p. 7 of Non-patent literature 5)and this is recorded. Patent document 1 (“means of resolution” andparagraph 36) shows the following. When collisions of edits to DB aredetected, DB (of server) that was correctly updated is sent in. Inpatent document 2, edit of later time is judged valid. In patentdocument 1, edit of more early time is judged valid. Neither of themresolves the above problem.

Patent document 3 is an invention about conditions of startingsynchronization of database. It describes synchronization method that“synchronizations are performed by changing editorial information”. Thisis merely a general concept of synchronization.

Patent document 4 is an invention of which purpose is to keep all dataof edit when competition of edit occurs. Original is updated only whenthere is no competition. Purpose and contents (of this document) differfrom the present invention. Although Patent document 5, 6, 7, 8, and 9were investigated, all differ from the present invention.

-   [Patent document 1] Patent application (JP) H9-91184, A-   [Patent document 2] Patent application (JP) 2004-13867, A-   [Patent document 3] Patent application (JP) 2004-86800, A-   [Patent document 4] Patent application (JP) 2006-284998, A-   [Patent document 5] Patent application (JP) H11-161535, A-   [Patent document 6] Patent application (JP) application document    2005-503606, A-   [Patent document 7] Patent application (JP) 2005-508050, A-   [Patent document 8] Patent application (JP) H8-16447, A-   [Patent document 9] Patent application (JP) 2000-501532, A-   [Non-patent literature 1] William R. Vaughn, Translated by Top    Studio, Yukio Ito as editorial supervision “Windows™, database    programming”, ADO.NET Specialization lecture Volume VB.NET, 4 Apr.    2003 (First Edition), SHOEISHA.-   [Non-patent literature 2] C&R Laboratory, “Super illustration: SQL    handbook”, (First Edition), 12, Aug., 2005-   [Non-patent literature 3] MSDN subscriptions library, “Outline of,    data concurrency control on AD.NET”, January 2007, (Disk File URL:    second-help://MS.MSDNQTR.v80.    ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dv_raddata/html/d5293    098-4a88-4110-abd2-34d9e6661664.htm))-   [Non-patent literature 4] MSDN subscriptions library, “Tutorial: A    process of a concurrency exception”, January 2007, (Disk File URL:    ms-help://MS.MSDNQTR.v80.    ja/MS.MSDN.v80/MS.VisualStudio.v80.ja/dv_raddata/html/73ee9    759-0a90-48a9-bf7b-9d6fc17bff93.htm)-   [Non-patent literature 5] “A World-wide Distributed File System    SKINNY”, IPSJ SIG Notes 95-S-70-1, (Academic Publication IPSJ SIG    Notes Vol. 95, No. 79 ISSN 0919-6072

DESCRIPTION OF THE INVENTION Problems to be solved by the Invention

Full-fledged parallel DB access is clarified. Problems of conventionalparallel DB edit based on cache are solved.

Means for Solving the Problem

The present invention is explained using the following examples.

(1) Preparation

Plural PCs have “duplicate DB”s (hereinafter “Local-original-DB”s),which are copy of initial state of the original DB (hereinafter“Global-original-DB”). These local-original-DBs have initials of ordinalnumbers which identify versions that can be used to identify turns oftheir updating. It is possible to judge validity of editorial contentsby these versions.

(2) Local Edit

Each PC performs local edit to each local-original-DB. Before the edit,a copy of local-original-DB for temporal editing work is created. Theedit is performed to this copy. Further at the time of edit, a set of“edit records”, which records contents of editing work, is created. Thisset of “edit records” includes at least “contents of the editing work”.In addition to this, the “edited version” may be included.

“Contents of editing work” are general editorial contents. For example,“what information was changed how”, “what information was added”, “whatinformation was deleted”, and so on. “Edited version” is a version oflocal-original-DB, which was target of the edit. Strictly saying, it(“edited version”) is a version of the local-original-DB, which was theoriginal of “copy to be target of the edit”.

(3) Sending “Edit Records” to Server

Each PC transmits “edit records” to server. When “edit records” and“edited version” are recorded separately, “edited version” withinformation indicating related “edit records” is also sent. Simple andrealistic way is a operation, in which “edit records” includes “editedversion.

(4) Receiving “Edit Records” by Server

The server records sets of “edit records” that arrived from PCs, andtheir turns of arriving.

(5) Receiving “Edit Records” from Server

PC asks the server for sending “edit records” that are not yet received.And PC receives them, and their turns by which they arrived to theserver. If “edited version” is specified to “edit records”, PC alsoreceives this.

(6) Renewal of Local-Original-DB

PC takes out sets of “edit records” by turns specified to them, judgesvalidity of them, and tries to update the local-original-DB by contentsof them. If version has been set, version of local-original-DB isupdated.

All PCs have same initial local-original-DBs. Each PC takes out sets of“edit records” in their turns (by which they arrived to the server), andupdates each local-original-DB. Each local-original-DB is updated, usingsame edit information, in same order, by same procedure logic. Eachlocal-original-DB will be same as results.

This mechanism enables that “each local-original-DB of PC synchronizeseach other, without updating global-original-DB of server”.

Main point is that “unique turn is attached to each set of edit recordscreated by each PC”. Though turns (by which they were sent up to theserver) are used here, it is possible to change these turns or to setother turns by another method. It is possible to change turns (by whichthey were sent up to the server), by another criteria (for example,priorities assigned to operators, and so on). It is sufficient, if “allPCs use same turns, by which each PC takes out and updates eachlocal-original-DB”.

For example, another method is the following. Turn (or time) of a set of“edit records” is determined by server or a specified PC, and isnotified (to a PC that creates or is holding the “edit records”). PC(that creates or is holding the “edit records”) writes this turn intothe “edit records” that will be exchanged among them. It is sufficient,if “all PCs use same turns, by which each PC takes out and updates eachlocal-original-DB”.

Since each PC updates reach duplicate DB at each convenient occasion,progresses of updating of local-original-DB of PCs vary in real time.However, local-original-DBs are in same status, if they were at justafter updating by a specific “edit records”. That is, eachlocal-original-DB of any PC synchronizes each other on common axis thatare turns assigned to sets of “edit records”.

Here, all PCs should have same “criteria of judging validity” and same“procedure of updating local-original-DB”. However, there is norestriction to these procedures, if they are same. Each set of “editrecords” is judged by same criteria, and all or some of them are judgedvalid or invalid. They are used to update local-original-DB in samemanner. Then, each local-original-DB of any PC synchronizes each otheron common axis that are turns assigned to sets of “edit records”.

A series of operations of a PC are explained. We assume that this PCreceived “edit records” of the latest from server and updatedlocal-original-DB. This PC performs an editing work to thislocal-original-DB, and sends up the “edit records”. During this editingwork, there is a possibility that another computer sent “edit records”to the server.

After the sending up of the previous et of “edit records”, sets of “editrecords” (which are not yet received till then) are received fromserver. They are taken out by the specified turns and are used to tryupdating the local-original-DB.

Finally, set of “edit records” that was sent up previously is taken out,and is judged about its validity, by investigating its “no-change rangeto be confirmed”. When it is judged invalid, operator of this PCconfirms the fact and the reasons, and tries to edit on the latestinformation again if necessary. If there are records of the previousinput, it is easy to input them again.

An operator of PC needs to know correctly, about “whether informationinputted by him became valid or not” and “in what situation theinformation became invalid”. This information is very important,because, “when offline edit is carried out in parallel DB access, theanswer to whether edit is effective cannot be obtained instantly. Itbecomes clear at the time of next synchronization.” Even wheninformation becomes invalid, all can be seen in PC, because all the setsof “edit records” are in this PC. “Process of judging the validity” and“situation of updating of local-original-DB” can be seen inside this PC.From this situation, it is possible to determine whether informationshould be input again, or should be abandoned.

The followings are itemized main points of the present invention.

(Updating 1) Each PC receives sets of “edit records” (that are not yetreceived) in order.(Updating 2) Received sets of “edit records” are taken out by theirspecified turns and are used for updating local-original-DB.(Edit 1) Each PC updates local-original-DB. A set of “edit records” ofthis updating will be sent up to server.(Premise 1) The contents of initial “local-original-DB” of each PC arethe same.(Premise 2) “Edit records” that is used for updating oflocal-original-DB by each PC are the same.(Premise 3) Turns assigned to sets of “edit records” used for updatingof local-original-DB by each PC are the same.(Premise 4) Each PC uses same logic for updating local-original-DB.

The above explanation did not explain about updating ofglobal-original-DB. Even if global-original-DB exists only as an initialof local-original-DB, there is no problem. If a program of PC can makeinitial DB, server does not need to have initial. Each local-original-DBof each PC synchronizes mutually. Thus, we can say that eachlocal-original-DB synchronizes to virtual (not existing)global-original-DB. Of course global-original-DB can exist actually.Global-original-DB will be updated by edit information. Whenlocal-original-DB of a certain PC was damaged, this PC can make copyfrom global-original-DB or from local-original-DB of any other PC. It isalso possible to re-create newest local-original-DB, from initialglobal-original-DB and all “edit records” till then.

(Substantially On-Line Operation)

The present invention does not specify details of criteria for judgingvalidity of “edit records”, nor details of updating procedure oflocal-original-DB″. However, it is natural to decide that edits based onold information are invalid. For lessening a possibility of edit of PCto be judged invalid, this PC will act as follows;

It receives “edit records” to the latest, before the editing work. Nextit updates local-original-DB. It edits the latest local-original-DB.Finally, it sends up the “edit records”, immediately after the edit.

If updated frequently, local-original-DB will always be maintained atthe latest state. It can be called “substantially on-line operation”.

(Substantially Off-Line Operation)

Suppose that information of rare competition of edit is treated. Thereis very small possibility that “edit to be judged invalid”, even if timefrom “updating local-original-DB by (Updating 1) and (Updating 2)” to“sending up of edit by (Edit 1)” is very long. For example, when eachorganization of a company inputs debit slips, these records will bemodified only if mistakes of input or handling are found. Most of thesemodifications will be done at the PC that input these records. In suchcases, the substantially off-line operation (that has long period from“updating” to “sending up recorded editing contents”) has very fewproblems. Even if connection to Internet is impossible, debit slips canbe inputted slowly. It is enough to send them up collectively, becomingnear the settlement or inspections.

(Improvement-1) Expansion of Inclusions of “Edit Records”

“Edit records” can include general “editorial contents” and “editedversions”, which were mentioned previously, and furthermore can include“range of version control” and “no-change range to be confirmed”, whichare explained in detail later. When setting versions to (one or plural)parts of DB, there are necessity to show “what version is treated” and“what part is corresponding to this version”. “Range of version control”shows this.

If “edit records” include general editorial contents and further include“edited version”, “range of version control” and “no-change range to beconfirmed”, they can be handled in a simple way. However, they are notnecessarily included in “edit records”. When they are recordedseparately, correspondences among them should be grasped by other PCs.

(Improvement-2) Introduction of “No-Change Range to be Confirmed”

“No-change range to be confirmed” is a range of affecting this edit. Ifinformation on this range has been changed, this means that “this editbecomes meaningless”. Various settings of “no-change range to beconfirmed” are possible, depending on information treated by DB,especially depending on characteristics of information that is a targetof edit. It is natural that “no-change range to be confirmed” includesinformation of target of edit. For relational DB (hereinafter, “RDB”),assumed are target table to be edited, tables logically related to thetable to be edited, some records in them, or whole of DB.

(Improvement-3) Manipulation of “Edit Records” and Turn Assigned

There is no necessity that “edit records” and a turn assigned to eachset of “edit records” should be the original contents at the time thatthey were sent up. If all PCs use same sets of “edit records” and sameturns that are assigned to them, each local-original-DB (to which these“edit records” were applied) synchronizes each other on common axis thatare turns assigned to sets of “edit records”.

Server or PC which performs administrative tasks may analyze “editrecords” and delete “portions which are repealed because of errors” or“redundant portions which perform nothing after all”. There is noproblem, even if a whole set of “edit records” is deleted by deletingportions of errors or redundant portions. Suppose that, turns (assignedto sets of “edit records”) were changed. If a sequence (by which thesesets will be used for updating each local-original-DB) is same at allPCs, local-original-DB of each PC synchronizes each other on common axisthat are turns assigned to sets of “edit records”.

There is no necessity that a unit, which is assigned a version and ismanaged about edit, should be actual DB. If “range of version control”is set to a portion (in which influence of updating is closely related)and version is assigned to each portion, edits and version transitionwill be easily managed.

Set up of “range of version control” depends on structure and contentsof information treated by DB, and needs knowledge of them. For “RDB”,assumed are records, tables, a group of tables logically related to thetable, some specified record among them, or whole of DB.

By reading DB as “range of version control”, processes already explainedin this specification are applicable. It is sufficient, if “editorialcontents”, “edited version”, “no-change range to be confirmed” arerecorded corresponding to each “range of version control”.

For DB of medical information, a lump of individual medical records inDB of medical information can be “range of version control”. If one or afew lines of table are information for an individual, a version is setup to them. DB contains many sets of personal information. A version isset up to each of them. “Edit records” can include single or plural setsof “editorial contents”, “edited version” and “no-change range to beconfirmed”. Each set is corresponding to each individual. “No-changerange to be confirmed” can be set up appropriately according to thecontents of updating. For example, it is set up to all records of anindividual or to a information (that is a record, when the DB is RDB)updated. If each table is constituted information of individual, versioncan be set up for each table.

It can be used for managing information of individual, not only medicalinformation but also social security, bank account, loan, and so on. Itcan also be used for management of offender information, which may beedited by plural sections. It is useful for handling individualinformation, such as “developed management of resident registration”, atwhich residents can edit some parts of their data by themselves.Local-original-DB can be created only for limited portion of personalinformation that is permitted by the authority of each PC, as explainedin “(Improvement-8) Limitation of range of local-original-DB” later.And, only information within the limits on the authority is sent to eachPC. Thus, there is no fear that hacked is information beyond theauthority,

When many sets of “edit records” gathered in server are not necessaryfor (an operator of) specific PC, it is sufficient that thelocal-original-DB synchronizes with only a part of global-original-DB.One implementation for this is a method skipping un-necessary “editrecords”, after receiving all “edit records”. If server picks up “editrecords” necessary for each PC and sends them to PC, communicationvolume will be decreased. When some unnecessary “edit records” areincluded, there is no problem if they are excluded by procedure of PC.If “edit records” (managed by server) were classified by “range ofversion control” included in edit information, listing up of “editrecords” (which should be sent to PC) can be judged quickly.

(Improvement-5) Timing of Setting Version

Version is set up to whole of the original DB (global-original-DB orlocal-original-DB) or to “range of version control”. Method of settingup them can be selected according to characteristic of informationtreated, or convenience of operation.

A version may be updated when the contents of local-original-DB areactually updated. Or, a version may be updated, whenever the original DBis tried to be updated by each “edit records”. It does not depend onexistence of valid updating.

(Improvement-6) Development: Reception Time of Edit by Server is used asa Version

Reception time of edit by server can be used as a version. “Version”that is explained in this specification will be read as reception time.Previously, version was explained as an ordinal number that identifies aturn in a sequence. There is no problem because time is also an originalnumber.

(Improvement-7) Development: Access Time for Synchronization to Serveris Used as a Version

From server, obtained is the time, at which the PC accessed server andconfirmed existence of “edit records” that had not yet been received.This time can be used as a version. At each confirmation, this time isset as version of local-original-DB, even if there are no un-received“edit records”. If there are sets of “edit records” that are not yetreceived, PC receives them, updates local-original-DB and sets up “thistime” as a version of the local-original-DB. Since priority is given toan editing work to local-original-DB with newer synchronization access,this rule is easy to be understood and can be convinced, by persons whooperate one DB by competition.

It is simple to explain, if we assume that local-original-DBsynchronizes with whole of (virtual or existing) global-original-DB.However, it is more practical that local-original-DB covers only someportion of global-original-DB. Although not only medical information butwhole DB is generally huge, DB is an aggregate of personal information,as explained in “(Improvement-4) Introduction of range of versioncontrol”. Local-original-DB of a patient's computer should have onlythis patient's information. Local-original-DB of a doctor's computershould have only the information of patients in charge. That is, thereis no necessity that local-original-DB synchronizes to whole ofglobal-original-DB. It is sufficient that local-original-DB synchronizesto some portions that are necessary for the PC. Thus, size oflocal-original-DB becomes small and the operation of synchronization(that maintains contents to the newest) becomes light.

(Improvement-9) A Variation on Assigning Turns to Sets of “Edit Records”

Server (or PC) that manages turn will be introduced. PC which created aset of “edit records” asks a turn to this server and writes assignedturn into the set. Even if sets of “edit records” are exchanged amongPCs directly, turns included in (written into) these sets are unique.Time can be written into a set of this “edit records”, instead of theturn. Needed is such a plan in which a specified PC manages time,against time difference among PCs.

(Improvement-10) Temporary Prohibition of Edit

It is convenient forbidding temporarily other edits, if parallel editingwork by other computer is impossible, such as a case in which datastructure of DB will be changed. For explanation, assumed is thefollowing situation: There is an edit (X). Parallel edits (to this edit)are prohibited. That is, editing work by other PC is prohibited from“the start of edit (X)” to “sending up to server after completing theedit (X)”. After X was sent, prohibition of parallel edit is canceled,from edit to local-original-DB that is updated by received “edit records(X)”.

One is a method repealing (by server) edits sent up in this prohibitionperiod. This is a positive way, by which edit X is employed efficientlyand makes no inconsistency. However, labor for making edits that arerepealed, becomes useless.

Another is a method telling prohibition period. PC of edit X candirectly notify other PCs, or notify server that notifies other PCs.

PC which performs edit X tells prohibition of edits by other PCs toserver, before performing edit X, at a time of requiring the “latestedit records” to server. After that, server tells the “prohibition ofedit” to other PCs which requires the “latest edit records”. Or, servertells it with response to inquiry of un-received “edit records”, etc.

After prohibition of edit was notified from server, PC does not performediting work, though this PC can update local-original-DB. And, PCrequests the latest “edit records” to server, and receives sets of “editrecords” to X. PC updates local-original-DB by “edit records X”. Afterthat, this PC starts editing work.

<Correspondence with Claims of the Original Submission>

“Parallel edit” of this specification is the following, “PC keeps andedits a local-original-DB inside. This local-original-DB (intuitively“duplicate DB”) is a copy of some parts of or whole of (virtual orexisting) global-original-DB (intuitively “the original DB”). Editinformation to duplicate DB kept by each PC is exchanged among PCs. EachPC updates each duplicate DB. Duplicated DB of each PC synchronizes eachother, because each PC uses same edit information, in same sequence andupdates each duplicate DB. Claim 1 expresses this. Claim 2 expressesClaim 1 as an apparatus.

At Claim 3, a procedure confirming validity of “edit records” was addedto the process D of Claim 1. At Claim 4, a concept of “no-change rangeto be confirmed” was added to Claim 3. By this concept, “procedure ofconfirming validity of edit records is performed. At Claim 5, a conceptof “version of duplicate DB” was added to Claim 3. By this concept,“procedure of confirming validity of edit records is performed. Claim 6is a case, in which a version is set up to a “part of information” or a“combination of information” of duplicate DB.

At “Claim 7”, a mechanism, by which version of duplicate DB is updatedeven if the validity is denied, is added to “Claim 5”. “Claim 8” is“Claim 5” with a process of setting a time as version of duplicate DB.By server, this time was written into “edit records” which was sent up.“Claim 9” is “Claim 5” with a process of setting a time as version ofduplicate DB. This time is the time at which PC accessed the server.This time was given from server.

EFFECT OF THE INVENTION

“DB access by server” has a problem, that is, “data access is impossiblewhen communication to server is impossible”. At mobile situation,communications are frequently impossible. This is a big restriction toDB operation. It is impossible to realize a request of continuations ofmission critical tasks, such as medical and financial activities andrelief at the time of a disaster.

Parallel DB edit solves this problem. But, pointed were several problemsof a method based on cache technology.

The present invention creates local-original-DB (that will synchronizewith virtual or existing global-original-DB) used as permanent cache.And local-original-DB will be synchronized to the global-original-DB,when required (at immediately before starting edit to local-original-DB,etc). This solves problems of conventional method of creating a copy foreach edit. The problems are “excessive load”, “judging validity ofcache” and so on.

When the conventional methods were used, it was difficult to detect thatinformation operated by a PC is amended by other PCs. However, thisfull-fledged “parallel DB (access) edit” can detect it easily. Afteroperator scrutinizes situation of edits, suitable action can be taken.Possible is to re-input data that became invalid, or to re-inputpartially updated data, or to accept the fact that the data becameinvalid.

There is no necessity that “object to be kept and synchronized bylocal-original-DB should be whole of the global-original-DB”. It issufficient if “the object is a portion of information (of the DB) thatis necessary for the computer”. There are examples of medicalinformation. Local-original-DB of a patient's computer only has thispatient's information. Local-original-DB of a doctor's computer only hasthe information of patients in charge. Thus, solved is an appropriateamount of cache that was a problem of the conventional methods.

Procedures, such as a procedure of judging validity of “edit records”,and a procedure of updating of local-original-DB, are performed by PC,not by the server. The followings are listed as the strong points ofthis mechanism.

(1) After receiving necessary sets of “edit records” and their turns,there is no need to communicate with the server. This makes quickresponses to subsequent operations of a user.(2) Procedure of updating local-original-DB is performed in PC. This PCcan investigate range of information (records) affected by a specificedit in detail.

Further, this PC can show more detailed information responding tooperator's request.

(3) Generally saying in many cases, each computer has unused capacities.Procedures are performed more quickly than they are placed in the serverto which processing loads are concentrated. This makes quick responsesto operations by users, with synergistic effects of above (1).

We can choose freely from “substantially on-line operation” to“substantially off-line operation”, adjusting interval of updating oflocal-original-DB. “Substantially on-line operation” that updateslocal-original-DB frequently is good for a case in which informationwith much edit access is treated. If data updating is performed by acomputer that initially input the original data (such as debit slips),or if data is not updated, “substantially off-line operation” can beused. This has no problem even if interval of updating oflocal-original-DB is extended extremely. There is no problem if theseedits are sent up collectively, becoming near the settlement orinspections.

Each PC can choose “substantially off-line operation” or “substantiallyon-line operation” according to each situation. Possible is mixedoperation in which both types of PCs exist simultaneously. It is a goodpoint.

BRIEF EXPLANATION OF FIGURE

FIG. 1. General structure of a computer

FIG. 2. Relation among server and PC

FIG. 3. Process of sending up “edit records” that was performed tolocal-original-DB, to server

FIG. 4. Process of receiving “edit records” from server

FIG. 5. Process of updating local-original-DB by “edit records”

FIG. 6. Simplified example

DESCRIPTION OF NOTATIONS

-   0100 Computer-   0102 Communication Unit-   0103 Arithmetic Unit-   0104 Main Memory Unit-   0105 DB (database) in Main Memory Unit-   0106 Secondary Memory-   0107 Input/output Unit-   0108 Monitor Unit-   0109 Bus-   0110 Communications Network-   0111 DB (database) in Secondary Memory-   0201 PC-   0202 Communications Network such as Internet-   0203 Server-   0204 Memory Unit of PC-   0205 Memory Unit of Server-   0206 Local-original-DB-   0207 Initial global-original-DB-   0208 Edit records-   0209 DB for temporal working-   0210 “Edit records” n-   0210 “Edit records” n+1-   0211 “Edit records” m-   0213 Means of editing-   0214 Means of updating-   0215 Means of sending-   0216 Means of receiving-   0217 Means of controlling sending and receiving-   0218 “Edit records” 1-   0219 “Edit records” m-   0220 Means of sending-   0221 Means of receiving-   0222 Means of controlling sending and receiving-   0301 Reserve memory area for “recording editorial contents”-   0302 Specify editing target information in local-original-DB-   0303 Specify a “range of version control” to which this “edit    records” belongs, and write it into this “edit records”-   0304 Fetch version of this “range of version control”, and write it    into this “edit records”-   0305 Specify “no-change range to be confirmed” corresponding to the    editing target information, and write it into this “edit records”-   0306 Write editorial contents and information specifying editing    target information, into this “edit records”-   0307 Create temporal working DB that was made by applying the    editorial contents (mentioned above) to local-original-DB-   0308 Send “edit records” to server-   0401 Notify server the last “edit records” of the previous time-   0402 Receive list of “set of edit records after the previous time”,    from server-   0403 Receive edit records-   0404 Put received “edit records” into unsettled list of “edit    records”-   0405 Confirm whether it is under “no-editing status” or not-   0501 Pick out an “edit records” from unsettled list of “edit    records”-   0502 Judge a validity of this “edit records” against the current    local-original-DB, by this “no-change range to be confirmed” and    “edited version”-   0503 Update local-original-DB-   0504 Update version of local-original-DB-   0602 PC-A-   0603 PC-B-   0604 Initial DB-   0605 Update local-original-DB of PC-A-   0606 Update local-original-DB of PC-B-   0608 Copy of record Z in PC-A-   0609 Copy of record Z in PC-A-   0610 Getting initial global-original-DB by PC-A-   0611 Getting initial global-original-DB by PC-B-   0612 Synchronization by PC-A-   0613 Edit by operator of PC-A-   0614 Sending “edit records” by PC-A. This is called “sending up edit    records”-   0616 Confirmation (notification to PC-A) and synchronization (by    PC-A). Here (and at explanations of any other notations),    synchronization is getting to the latest set of “edit records” and    turns assigned to them.-   0617 Synchronization (by PC-B)-   0618 Edit by a operator of PC-B.-   0619 Sending “edit records” by PC-B. This is called “sending up edit    records”-   0621 Confirmation (notification to PC-B) and synchronization (by    PC-B)-   0622 Synchronization by PC-B-   0623 Modification on copy of record Z of PC-A by “edit records” by    PC-B

BEST MODE OF CARRYING OUT THE INVENTION

The present invention can be implemented as a program of computer. FIG.1 shows typical structure of computer 0101. Arithmetic Unit 0103, MainMemory Unit 0104, Secondary Memory 0106, Input/output Unit 0107, andMonitor Unit 0108 are connected by bus 0109. When exchanging databetween other computers, it is connected to communication network 0101via communication unit 0102. “Database” referred by each claim is DB0111 in secondary memory 0106 or DB 0105 in main memory unit 0104.

Program recorded in secondary memory 0106 is loaded in main memory unit0104 at invoking. Arithmetic unit 0103 works as instructed by theprogram. As a result, computer is reconfigured as an aggregate of meansthat are intended by the program developer.

After loading (some parts of or whole of) DB to main memory unit 0104,program handles DB in general cases. Parts (or whole) of DB 0111 insecondary memory 0106 will be loaded as DB 0105 in main memory 0104.Operations are performed to this DB 0105 and the editorial contents willbe written into DB 0111 in secondary memory 9195. But usually, it isassumed that DB is in secondary memory 0106. At discussion, there is nodistinction between it and DB 0105 loaded to main memory 0104. Thus,FIG. 2 simply shows DB in memory unit 0204, 0205.

PC 0201 receives sets of “edit records” 0218, 0219 (which were placed inserver 0203), and updates Local-original-DB 0206. FIG. 2 explains thiscase. PC 0201 is connected to server 0203 via communications networksuch as Internet 0202. Though generally there are plural PCs, FIG. 2shows one PC.

PC 0201 has memory unit 0204, in which local-original-DB 0206 isrecorded. Initial of local-original-DB is a copy of initialglobal-original-DB 0207. “Means of editing” 0213 performs edit underinstructions of an operator. At this time, local-original-DB 0206 doesnot be edited directly. Results of this edit will be temporal working DB0209. Simultaneously, “edit records” 0208 will be created. This set of“edit records” contain “edited version”, which is a version that was setto the local-original-DB.

“Means of sending” 0215 sends “edit records” 0208 to server 0203 viacommunications network 0202. “Means of receiving” 0221 of server 0203receives them, which are added to a sequence of “edit records” 1 (0218)and “edit records” m (0219). “Edit records” include “edited version”,and so on. If “edited version” is sent to server (aside from “editrecords”), server records correspondence among them.

When PC 0201 tries to update local-original-DB 0206, PC at first asksserver for sending “edit records” that are not yet received. Afternotification (by PC 0201) of the version of the last “edit records”received, “means of controlling sending and receiving” selects “editrecords” that are after the notified version. And “means of sending”0220 sends them from server. “Means of controlling sending andreceiving” 0217 manages cooperation among receiving and sending by a PC.“Means of controlling sending and receiving” 0222 manages cooperationamong receiving and sending by a server.

“Receiving means” 0216 of PC 0201 receives “edit records” n (0210),“edit records” n+1 (2011) and “edit records” m (0212), which will berecorded in memory unit 0204. “Updating means” 0214 takes out them inorder of their turns, evaluates their validity, updateslocal-original-DB 0206 and updates its version.

FIG. 3 shows a process of sending up (to server) “records of edits”(namely, “edit records”) to local-original-DB that is held by PC. Atfirst, “reserve memory area for recording editorial contents” 0301.Specify editing target information in local-original-DB (0302). Specifya “range of version control” to which this “edit records” belongs, andwrite it into this “edit records” (0303). Further, fetch version of this“range of version control”, and write it into this “edit records”(0304). Specify “no-change range to be confirmed” corresponding to theediting target information, and write it into this “edit records”(0305). Write “editorial contents” and “information specifying editingtarget information” into this “edit records” (0306). And, createtemporal working DB that was made by applying the editorial contents(mentioned above) to local-original-DB (0307). Send “edit records” toserver (0308).

FIG. 4 shows process of receiving sets of “edit records” and “turns thatwere assigned to them”, from server. At first, notify server the last“edit records” of the previous time (0401). From the server, receive alist of “edit records” that are after the previous time (0402).According to this list, receive “edit records” (0403), and put received“edit records” to unsettled list of “edit records” (0404). Finally,confirm whether it is under “no-editing status” or not (0405). Even ifit is under “no-editing status”, “means of updating” 0214 updates (asshown in FIG. 5) local-original-DB by “edit records” that are receivedfrom server. However, “edit of local-original-DB 0206 by editing means0213 (and procedure of FIG. 3)” and “sending edit records to server”will not be invoked.

FIG. 5 shows process of “means of updating” 0214 that updateslocal-original-DB by “edit records” received from server. Pick out an“edit records” from unsettled list of “edit records”, that is a list of“edit records” n (0210), “edit records” n+1 (2011), “edit records” m(0212) (0501). Judge validity of (edit records) against the currentlocal-original-DB, by this “no-change range to be confirmed” and “editedversion” (0502). When valid, update local-original-DB (0503), and updateversion of local-original-DB (0504). Repeat these processes for all“edit records” in the list of unsettled “edit records”.

If a set of “edit records” includes “edited version”, which is a time atwhich server received it, this is set as version of local-original-DB.If a version is a time at which server was asked about existence of“edit records” that are not yet received (by a PC), this time isobtained by the process 4 of FIG. 4. This time is set as version oflocal-original-DB, at the last of processes of FIG. 5 (just before theending).

FIG. 6 shows transitions of a version, as an example. DB of FIG. 6 isRDB. Version is integer. “No-change range to be confirmed” is a recordthat has been edited. Here, each record keeps “version of record” thatwas the “edited version” at the time of the edit to this record.

PC-A 0602 and PC-B 0603 get (0610) initial global-original-DB 0604 astheir local-original-DBs 0605, 0606. Base versions of them are zero,because they are copies of initial global-original-DB 0604 in server.After that, edit 1 to 6 were sent up. These were sent up by PCs otherthan PC-A0602 and PC-B0603. In FIG. 2, PC-A 0602 accesses again toserver, and gets the latest edit and its turn (0612). At this time,getting edit 1, version of local-original-DB changes to 1.

Now suppose that, “operator of PC-A 0602 edits copy of record Z 0608contained in local-original-DB 0605” (0613). At this time, “version ofrecord” of edited “copy of record Z 0608” becomes 1, because baseversion of local-original-DB 0605 is 1. This set of “edit records” issent (0614), and is recorded as edit 7. Immediately after this, PC-A0602 receives “edit 2 to edit 6”, which were sent up after “edit 1”(that was already received).

PC-A confirms that the set previously sent up became “edit 7”, andinvestigates “edits to 7” in their turns, by “judging validity of edits”(that has been specified beforehand). Here, suppose that “edit 7” isjudged valid. Base version of local-original-DB 0605 is changed to 7.

On the other hand, PC-B 0603 gets “edit 1” to “edit 6” (that is thelatest edit at the time of this synchronization 0617) from server 0601,updates local-original-DB 0606 and sets 6 as its base version. Afterthat, suppose that operator of PC-B 0603 edited “copy of record Z” 0609.At this time, “version of record” of “copy of record Z” 0609 changed to6. This is sent up to server (0619), and was recorded as edit 8.

And, “edit 9” is sent up. After that, PC-A 0602 accesses server 0601 andgets “edit 8 and edit 9”, which were sent up after “edit 7” (that wasalready received) (0622). “Edit 8 and edit 9” are took out according totheir turns. Validity of these edits will be judged, andlocal-original-DB 0608 will be updated. Here, base version of duplicateDB 0608 changes to 9, because the local-original-DB 0608 was updated by“edit 9”. At this time, contents of “copy of record Z” (that was editedby PC-B 0603) become valid in local-original-DB 0605 of PC-A 0602. PC-A0602 finds out that “copy of record Z 0608 (that was edited previouslyby PC-A 0602) became invalid”.

INDUSTRIAL APPLICABILITY

As a popular operation, plural computers access a database placed inserver. But problem is that “edit is impossible if access to server isimpossible”. The present invention shows full-fledged parallel DB editin which permanent duplicate DBs are kept in computers. This isapplicable to a situation in which communications are frequentlyimpossible, such as mobile device and mission critical tasks, forexample medical and financial activities and relief at the time of adisaster.

1. A method of editing database, comprising; (A) holding a duplicationof whole or a part of a database, (B) a process of sending “editrecords” of edit on said copy, to another apparatus, and (C) a processof receiving “edit records” on said copy, from another apparatus, and(D) a process of executing the following sequence of steps; fetching aset of “edit records” in order of turns assigned by exterior, orspecified to each set of “edit records”, and updating said copy ofdatabase by said set of “edit records”.
 2. Apparatus editing database,comprising; (A) means of holding a duplication of whole or a part of adatabase, and (B) means of sending “edit records” of edit on said copy,to another apparatus, and (C) means of receiving “edit records” on saidcopy, from another apparatus, and (D) means of executing the followingsequence of steps; fetching a set of “edit records” in order of turnsassigned by exterior, or specified to each set of “edit records”, andupdating said copy of database by said set of “edit records”.
 3. Amethod of editing database, comprising; A method to edit database,comprising; (A) holding a duplication of whole or a part of a database,(B) a process of sending “edit records” of edit on said copy, to anotherapparatus, and (C) a process of receiving “edit records” on said copy,from another apparatus, and (D1) a process of executing the followingsequence of steps; fetching “edit records” in order of turns assigned byexterior, or specified to each set of “edit records”, judging validityof said set of “edit records”, and updating said copy of database bysaid valid set of “edit records”.
 4. A method of editing database,comprising; (B1) a process of setting mapping between “edit records” ofedit on said copy and “no-change range to be confirmed” which indicatesrange of information affected, and sending said “edit records” toanother apparatus, and (C1) a process of receiving “edit records” onsaid copy and “no-change range to be confirmed” mapped to said editrecords, from another apparatus, and (D2) a process of executing thefollowing sequence of steps; fetching edit records in order of ordinalnumber assigned by exterior, or specified to the edit records, judgingvalidity of said edit records by “no-change range to be confirmed”mapped said edit records and updating said copy of database by saidvalid edit records.
 5. A method of editing database, comprising; (A)holding a duplication of whole or a part of a database, (B2) a processof setting mapping between “edit records” of edit on said copy and aversion which is assigned to said copy, and sending said “edit records”to another apparatus, and (C2) a process receiving a set of “editrecords” on said copy and a version mapped to said set of “edit records”from another apparatus, and (D3) a process of executing the followingsequence of steps; fetching a set of “edit records” in order of turnsassigned by exterior, or specified to each set of “edit records”,judging validity of said set of “edit records” by version mapped saidedit records and updating said copy of database by said valid set of“edit records”, and updating its version.
 6. A method of editingdatabase, comprising; (A) holding a duplication of whole or a part of adatabase, (B3) a process of setting mapping between “edit records” ofedit on said duplication and a version which is assigned to a part ofsaid information or combination of information of said copy, and sendingsaid “edit records” to another apparatus, and (C2) a process receiving aset of “edit records” on said duplication and a version mapped to saidset of “edit records”, from another apparatus, and (D3) a processexecuting the following sequence of steps; fetching a set of “editrecords” in order of turns assigned by exterior, or specified to saidset of “edit records”, judging validity of said set of “edit records” byversion mapped said set of “edit records” and updating said duplicationof database by said valid edit records, and updating its version.
 7. Amethod editing database, comprising; (A) holding a duplication of wholeor a part of a database, (B2) a process of setting mapping between editrecords of editing work on said duplication and a version which isassigned to said copy, and sending said edit records to anotherapparatus, and (C2) a process receiving edit records on said copy and aversion mapped to said edit records from another apparatus, and (D4) aprocess executing the following sequence of steps; fetching edit recordsin order of ordinal number assigned by exterior, or specified to theedit records, judging validity of said edit records by version mappedsaid edit records, and updating version of said duplication of database,and updating said duplication of database by said valid edit records. 8.A method of editing database, comprising; (A) holding a duplication ofwhole or a part of a database, (B2) a process of setting mapping between“edit records” of editing work on said duplication and a version whichis assigned to said duplication, and sending said edit records toanother apparatus, and (C3) a process of receiving a set of “editrecords” on said duplication and date and time mapped to said “editrecords” from another apparatus, and (D5) a process of executing thefollowing sequence of steps; fetching a set of “edit records” in orderof turns assigned by exterior, or specified to said set of “editrecords”, judging validity of said set of “edit records” by versionmapped to said set of “edit records”, and updating said duplication bysaid valid set of “edit records”, and. setting date and time assigned tosaid set of “edit records” as version of said duplication.
 9. A methodto edit database, comprising; (A) holding a duplication of whole or apart of a database, (B2) a process of setting mapping between “editrecords” of edit on said duplication and a version which is assigned tosaid duplication, and sending said “edit records” to another apparatus,and (C4) a process of sequence of steps; receiving set of “edit records”on said duplication and version mapped to said set of “edit records”from another apparatus, further receiving date and time, and (D3) aprocess of executing the following sequence of steps; fetching a set of“edit records” in order of turns assigned by exterior, or specified tosaid set of “edit records”, judging validity of said set of “editrecords” by version mapped to said set of “edit records”, updating saidduplication of database by said valid set of “edit records”, and settingdate and time that are received by process (C4) as version of saidduplication.